Rock Raider Menu System 


There are a number for reasons starting this now. 


Politically: 


There are large number of non-technical people at Lego who will judge the 
game by appearances. E.g Mark Livingstone, Petra, Connie etc. If they feel confident 
that the game is progressing, then we are more likely to get the current work that they 
are offering us. 

They will not play the game themselves, they will ask the QA and project managers 
and they will see progress as playability and functionality. 








If they see that 1/3 of the game is not there, particularly the first 1/3 of the game that 
children see, (the attract mode) is not even properly attempted by Alpha, 

They can’t see what isn’t there, so they don’t know ‘x’ Menu . options screens are 
NOT ATTRACT MODES. most people skip past them, the game is the attract mode 
no EVER says worth buying for the menu options screens. 











they may decide to put a hold on the other work — until we catch up!.or they may not, 
being behind on the project so far has not prevented us from getting animation, 
storyboard, comic strips, tv ads, promo models and many more bits. The fact that the 
programming of this is trivial will be besides the point, they will judge what they see. 
They don’t judge what they don’t see. It is the judging and feedback and time ‘used’ 
to do all of this judging which is wasted as this work will alter, causing more delays, 
and slipage.If the style, size, colours, ease of use and visual understanding all come 
within the Lego philosophy etc. they will still feel that we have this close synergy 
with them. You may argue that if we get it wrong, they may want changes but I would 
rather they feel that they have plenty of time to do these modifications and get the 
appropriate feedback. We won’t have the time to do the changes, it is tight now and 
doing and redoing takes longer.If they don’t like it when presented at the project end 
then they will feel they have been sold a lemon, because it did not fit their criteria and 
they can’t even put it on the shelves. If they want changes we will do it, by not 
causing additional delays now we will have more time to do the changes and kee 
them happyThey put all 3 Lego games out on the shelves in November as scheduled. 
The games may be cut down versions but they made the shelves. This shows us that 
TIME is the most critical issue, if we shove in a naff menu system, and time runs out 
THEY WILL STICK WITH IT, that’s what they have done with these three games, 
they have bugs in them and they shipped them out! 


Personal Relationship: 


We have promised Tom that he will have Alpha by the end of this month. This 
stipulation demands that we have the front-end on. It does not mean that all the 
playability has to be in it. If we can’t do it we can’t do it, if you can think up a 
way of speeding up production (you say no one is working to full capacity then do 









































it) but bodging a temporary fix, which will cause a longer delay later is making 


more trouble. We miss this one and get the next milestone. By missing this 
deadline we will put him in a bad position with Lego and he will then cycle into 
reverse demanding daily/weekly updates in order to cover his ass. (to put this right 
we need to speed up production not fudge it)This is already starting to happen as 
even though, he knows we are pushing for Alpha he wants an Alpha scheduled 
report by the end of this week. (He will turn into Andy from Eidos and his visits 
will be more frequent and less friendly). Again (to put this right we need to speed 
up production not fudge it) we temporarily please cidos with a false milestone 
which then caused bigger delays, which lost us even more dearly. 

















Programmer Time Impact 


We do not have to spend much of Paul or Rob’s time (time is short, it is all 
important) as this is a separate module, which we can integrate. Scott Williams, 
Tony Stoddart or even Karl (god help us) could be used (Karl could be used but it 
isn’t only the time, it is the knowing what to do, the time is wasted in getting the 
reports back with changes which we do (wasting more time) or don’t (upsetting 
Lego) If we just want any old menu system in there we already have one from 
Karl and Paul I wouldn’t want either to be shown . There will be teething 
problems, re CE but I am sure that a separate Front-end that would be far better, 
than no-front-end till the end of the project. This front-end merging would happen 
only once rather than multiple times (remember CE we spend ages messing with 
memory, variables, and allsorts with a separate ‘once only’ fix front end) when, at 
the end they would keep asking for changes that could have been ironed out much 
earlier. This is exactly where time is wasted, they would ask for changes (we 
would do them) then we alter it and it has to be done again! 























We do have more available artist time, which could be utilised for BMP’s even 
Avi’s etc. to gain much of the info we need. I am not suggesting huge FMV’s but 
mockups could be submitted for approval. What is the point of approval if it 


changes! 





The Age-Range 


This game is for 7-10 year olds and to be confident that this age range can play the 
game, it must be suitably tested on this range. Focus testing will require time (tell me 
how we can save or make more time) and if we hand them an almost ‘finished’ game 





before we do the front-end they will surely, hold any bad publicity on the ‘ease of 
use’ against us. If I could turn back time to CE and have just 1 month to change 
things,(how could we save time!) it would only be to listen to what the Americans, 
Germans and British reviewers were telling us.(I agree we need feedback, the issue is 





| time to get this and do the changes) Apart from gameplay issues their biggest 
problems were: 


i.e. 

Make the game easier to get into (menu wise) 

Have a simple control method 

Make it easier to understand what the icons mean and what you have to do. 





By getting feedback on these issues early enough (feedback too early is worse than no 
use, because it causes delays, getting feedback on the original 4 screen Ocean CE 
would have had no bearing whatsoever on the finished game, we would have spent 
time ‘fixing the 4 screens, making the selection of them nice, then changed it all to a 
single hi res screen) We HAVE TO HAVE FEEDBACK, but on the right work, we 
had feedback on CE they didn’t like it, we didn’t like it, TIME was our problem, we 
spent it fudging the game to hit milestones. We could have had a menu system in 
now, and less game play, I think this would be wrong, Tom is happier with ‘seein 
things happening’ rather than a menu screen and a static game screen.we can avoid 
some of the pitfalls we hit with CE. Our attitude was wrong, we did a game for us and 
not a game that the public wanted. We should have listened to the feedback and 
adjusted accordingly, but as we got our feedback so late in the development process, it 


was too late to do anything about it.This is right, but I believe that a reason why the 
development was so late was the fudging of the game to fit the milestones. 


























Value of Early Focus Testing 


Lego has a lot to say about the style of the game and take a very long time to decide 
what colour a hat should be. They no doubt have focus test results that will favour one 
colour as opposed to the next. There is no doubt strong financial reasons for doing this 
depth of testing. 


Information that would be useful for us to know when developing a menu system. 


What colours did the kids like that was offered, that still fits in with the style of the 
game. Is the style too hard for the kid to differentiate between foreground and 
background colours. 


What is a suitable size Icon for a 7 year old, does he find clicking on a 16x16 icon 
ergonomically frustrating. Is that size of icon too small and unappealing in terms of 
the graphic picture, so that he loses interest. Would he feel happier with a 24x24 or 
32x32 that is spread over two screens. 


What font and size is readable for a 7 year old. Perhaps a monochromatic colour is 
readable for him, but he will not read it because it is not pretty and he will then miss 
valuable information leading him to the conclusion that the game is hard. Perhaps 
pretty coloured fonts are attractive but too difficult to read. 


What style of control method should we use. Horizontal scrolling or do they prefer 
Vertical scrolling, or typing in numbers or using counters. Maybe they can click the 
ends of the scroll bar arrows but do not realize about dragging the middle box section. 


Are kids better at looking at a non moving static screen or could we use a 3D ‘piston’ 
type scroll bar instead of a flat one. 


What text words does a kid understand, can we use ‘Ambience’ or is there a simple 
alternative, perhaps graphically demonstrated. 


What size, shape, particularly position, colour should the Exit buttons, ‘Go back’, ’Go 
forward’ be. That would still fit in with the style. 


Should we have a ‘Captain’ Advisor for the help screens as well. Perhaps he could 
appear beside each option giving information or should we use just a text tip info and 
audio or leave it like other games. Such and easy menu system could be hailed as 
great by Lego, but if left to the end will never happen. 


As we experiment through the menus system we will find features, we would like to 
implement e.g. reset default settings, save settings etc. There will be others as we 
develop the game but this is better being found sooner rather than patching it in later. 


Are kids better at sub menus or would they prefer more crammed screens but not sub- 


menus. 


L agree with all of this wholehartedly, no question. See previous comment for 
feedback on the wrong data 





Wrong data and they like it— no use because we have to take it out, or worse upset 
lego as we change it and they liked it!! 








Wrong data and they don’t like it — no use and it upsets Lego that we are getting 
thinks wrong 


Right data — and they like it — great we did it right and we have lost nothing, just a 
different time schedule. 








Right data and they don’t like it — we have to spend time changing it (which we have 
to do some time anyway!) and we get it right (potentially we will spend more time on 
the interface and lose out on the game play, as we did in CE and they will ship it with 
less game content. 














From the above options they all cause delays in the project only the right data and the 
right time is a good option. 

Next best is right data and they don’t like it, this is optimised by us giving them the 
right data (which is later on in the project as more of the data will be finalised and will 


be right) 














The wrong data options waste time, which will cause us to do less menu fixes that 
they ask for, this is exactly what we don’t want. 


Conclusion 





Taking into account all of the points above will help give us a tried and tested menu 
system that will be bug-free (until merging), be approved and liked by Lego (but it 
will not be approved WHEN we have to change it) and be easy for the kids to 
understand. (until we change it and then need re-approval) If written flexibly, 
additions, changes etc, can be added with little detriment. (additions and changes 
NEVER go smoothly, alterations generally cause more problems than writing it 


correctly from the start. 














Our greatest resource is the artists, who do not do things right first time and generally 
need a lot of corrections. We had the exact in-game models since April and I still find 
fault/ enhancements to them. (then we don’t have spare artists, we have artists that 
have work to do right now) It took 6 attempts to get the style of the in-game ‘button’ 
right and almost 2 months for Tom to confirm that was the style he was after.(and this 
time is now wasted as we are going to change it, and then need retesting and 
evaluation He will not be happy to approve anything that has not gone through 
Billund, focus testing etc. but will loudly blame us for any synergy problems that may 
arise. Also, by giving him things to approve, it keeps him occupied and gives us 
excuses should we need them.(this is the fob off Andy and it will all be alright, but it 
always comes back to us, WHEN we are late because we have done another 3 
different menu options screens and spent all the time testing and changing them, then 
WE will get the blame for being late. 




















IF CE had 95% reviews sold 500,000 copies but was several months late, they would 
have forgiven us. Instead it was slated for the control method, ease of use and the 
most unforgivable confusing menu system created. (Matt Miller) This is exactly right, 
what we needed was a better system than the one we stuck with. We need to do the 


right menu, icon, selections, not one Karl is going to cobble together and we will end 
up having to stick with. 











TIME is our biggest problem 
1 hit monthly milestones if possible 
2 priority is for the final deadline (Lego will launch it ready or not) 











Control system needs to 
1 work in the game, have all the nessassary options and no supuflious ones 
2 be user friendly , assessed and approved by focus groups 











GAMEPLAY 
It would be nice to have a playable game at the end of it all, as well as a ‘tick list approved 


game’ 
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